Add RTL8811AU support via RF_TYPE_ID autodetect#21
Closed
josephnef wants to merge 1 commit into
Closed
Conversation
RTL8811AU is the 1T1R cut of the same Jaguar silicon as RTL8812AU. The 1T1R BB/RF/TX-power paths are already implemented (PHY_BB8812_Config_1T, numTotalRfPath loops, per-BW L1pkVal branches) but were unreachable because read_chip_version_8812a hardcoded RFType=RF_TYPE_2T2R. - EepromManager: derive RFType from REG_SYS_CFG bit 27 (RF_TYPE_ID); keep registry_priv::special_rf_path as a manual override for mis-burnt EFUSE. - demo: try a small allow-list of known Realtek PIDs (0x8812, 0x0811, 0xa811, 0xb811) instead of hardcoding 0x8812. PID 0xc811 is intentionally excluded because it is shared with the unrelated RTL8811CU chipset. Refs #20 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Much more code has to be added #22 |
This was referenced May 19, 2026
josephnef
added a commit
that referenced
this pull request
May 21, 2026
## Summary Adds support for the RTL8814AU (VID/PID `0bda:8813`) — Realtek's 4T4R / 3-SS Jaguar-family chip. Verified on COMFAST CF-938AC: monitor-mode RX receives real 802.11 frames on both 2.4 GHz and 5 GHz bands. TX infrastructure is in place but not validated end-to-end. Stacked on PR #21 (RTL8811AU support). The first commit on this branch is identical to PR #21; once #21 merges this PR can be rebased. ## Highlights - `Rtl8812aDevice` → `RtlJaguarDevice` rename (deprecated alias kept for one release). - Chip-version detection in `EepromManager` (8813 → `CHIP_8814A`, RF_TYPE_4T4R, max 3 spatial streams). - 8814 vendor data: `hal8814a_fw.[ch]` blob (~68 KB), `Hal8814PhyReg.h`, `Hal8814PwrSeq.[ch]`, phydm phy_reg + agc_tab tables auto-generated from upstream phydm. - New `PhyTableLoader` that runtime-evaluates phydm `IF/ELSE_IF/ENDIF` opcodes against chip-cut + interface + rfe — the phydm "compile out non-matching branches" approach doesn't fit a userspace driver that may serve multiple board variants. - `FirmwareManager::FirmwareDownload_8814A` — RSVD-page TX via beacon queue + IDDMA copy to 3081 DMEM/IMEM (the 8814 download path is structurally different from the 8812's page-mapped vendor write). - BB/RF domain power-on after fwdl (`REG_SYS_FUNC_EN`, `REG_SYS_CFG3_8814A+2`, `REG_RF_CTRL[0..3]`) — without this the BB writes silently no-op on the chip side. - Post-fwdl EFUSE read (`EepromManager::LateInitFor8814A`) — the chip rejects EFUSE reads pre-fwdl, so the constructor skips them on 8814 and `LateInit` re-runs the parsers against real data once firmware is up. - `RadioManagementModule` loops scaled to up to 4 RF paths; path-C/D writes; path-A/B-only reads (matches rtw88's behaviour — the chip's 3-wire SI/PI mechanism doesn't support C/D reads). - `FrameParser` populates path-C/D RSSI + SNR slots from the 8814 RX descriptor. - Demo env vars: `DEVOURER_PID`, `DEVOURER_CHANNEL`, `DEVOURER_SKIP_RESET`, `DEVOURER_FORCE_TXPWR`. ## Known limitations - **TX not validated end-to-end** on 8814. Descriptor layout and rate mapping look correct, USB endpoint priority is wired up, but no injected-beacon → peer-sniffer test has been performed yet. The TX-power-by-rate loop (~370 control transfers, 20–30s) is skipped by default in monitor mode for this reason. - **`rfe_type` from EFUSE only verified on CF-938AC** (returns 1). Other 8814 boards may report different RFE options that exercise BB-table branches we haven't touched. Falls back to `rfe_type=1` if EFUSE doesn't carry a value. - **160 MHz BW is out of scope.** The silicon supports it but no lab path validates it. - **Path-C/D RF reads are not supported** by the chip's 3-wire SI/PI mechanism. This is upstream rtw88's behaviour as well (`rtw88xxa_phy_read_rf` only indexes paths A/B). ## Test plan - [x] Build clean: `cmake -S . -B build && cmake --build build` - [x] 8812 regression on existing adapter - [x] 8814 RX on CF-938AC, 2.4 GHz channel 6 — beacons + probe req/resp + data frames received - [x] 8814 RX on CF-938AC, 5 GHz — frames received - [ ] 8814 TX → peer sniffer (deferred; TX path not yet validated) - [ ] 8814 RX on a second board with a non-CF-938AC EFUSE (deferred; no second board available) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Collaborator
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
EepromManager::read_chip_version_8812ahardcodedRFType = RF_TYPE_2T2R, so the existing 1T1R code paths (PHY_BB8812_Config_1T, thenumTotalRfPathloops inPHY_RF6052_Config_8812/ TX power, per-BWL1pkValbranches, 2.4 GHz eLNA threshold) were unreachable on RTL8811AU dongles even though the driver could otherwise drive the chip.RFTypefromREG_SYS_CFGbit 27 (RF_TYPE_ID) the same way Realtek's upstream rtl8812au driver does — set → 1T1R (RTL8811AU), clear → 2T2R (RTL8812AU). Same firmware, same power sequence, same EFUSE layout; only the chain count and a handful of BB constants differ, all of which are already conditionalised.registry_priv::special_rf_path == 1still forces 1T1R after autodetect, in case a board's EFUSE/strap is mis-burnt.demo/main.cppnow tries0x8812 → 0x0811 → 0xa811 → 0xb811before giving up.0xc811is intentionally excluded — it is shared with the unrelated RTL8811CU chipset, which uses a different driver family entirely and is not supported by this code.Test plan
Need hardware verification before merge:
WiFiDriverDemo, confirm log showsRF_Type is 2 TotalTxPath is 2and beacon RX still works on ch36/20 MHz.lsusb— VID0bda, PID one of0811/a811/b811/8812, notc811), runWiFiDriverDemo, confirm log showsRF_Type is 0 TotalTxPath is 1and beacons are received.WiFiDriverTxDemoon the 8811AU and confirm the hardcoded beacon is seen by a separate sniffer.kRealtekProductIdstable still links under_MSC_VER,__ANDROID__,__APPLE__paths (compile-tested on macOS; the table isstatic constexpr, no platform-specific behaviour).Open questions for the reporter (#20)
lsusbshow for your dongle? We need the exact VID:PID to confirm it's an AU and not a CU (which we can't support — separate silicon, separate driver).registry_priv::RFE_Type = 64andAmplifierType_*defaults may need adjusting based on whatHal_ReadRFEType_8812Areports from your EFUSE.TxBBSwing_*defaults are EFUSE-driven; calibration on 1T1R SKUs may surface tuning needs.Refs #20
🤖 Generated with Claude Code